Native Ollama + Gemini chat backends, replacing the OpenAI chat/completions
compatibility shim. Conversation history now owned by the bot and persisted
in Redis so it survives restarts.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Defines a small tool registry (lib/tools.js) that Data can choose from on
each turn: generate_image, tell_dad_joke, state_asimovs_laws, show_help,
start_dance_party, play_rickroll, play_tiktok. handleMessage gains a
dispatch loop (capped at 5 iterations) that runs tool calls and feeds
results back as tool-role messages until the model returns plain text.

Both chat adapters now translate the canonical { tools, toolCalls } shape
to/from their native wire format:

- Ollama: { type: 'function', function: {...} } and tool_calls on the
  assistant message; tool-role results carry tool_name.
- Gemini: functionDeclarations under config.tools, functionCall parts
  in candidates, functionResponse parts for tool results.

Tool round-trip traffic stays ephemeral inside the dispatch loop — only
the final assistant text is persisted to convoStore so conversation
history remains a clean user/assistant alternation.

Per-message tool registries are built in app.js so closures bind the
right Slack channel for upload + post side effects. The makeTools
factory accepts rng and sleep so tests can pin the dad-joke zinger
without 10-second waits.

Drops the isImageRequest matcher + IMAGE_REQUEST_GUIDANCE shim entirely
— Data now just generates the image when asked instead of telling the
user to type /image.

Verified live against gemma4:31b on kepler.local:
- "Draw me a picture of a sehlat." -> tool call with a rich prompt,
  upload posted, reply "I have generated an image of a sehlat for you."
- "What is 2 + 2?" -> "Four." (no tool calls when not needed)

53 tests pass (17 new across chat/chat-backends/tools/responses), lint
clean.

Closes #25
Co-Authored-By: Claude Opus 4.7 <[email protected]>

Detects image attachments on incoming Slack messages, fetches each via
the Slack file URL with the bot token, base64-encodes and attaches to
the user turn in the canonical chat shape as
`images: [{mimeType, data}]`.

Both adapters translate to their native wire format:

- Ollama: Message.images is a list of base64 strings (mimeType ignored).
- Gemini: parts get { inlineData: { mimeType, data } } interleaved with
  the text part.

Image bytes are NOT persisted to convoStore — only the text portion of
the user turn lands in history. The Slack file URLs would expire even
if we did, and the bytes are big.

Empty text plus images is now a valid turn (the model handles "what
is this?" implicitly). Truly empty messages (no text, no files) still
short-circuit before reaching the LLM.

In app.js, both the DM/MPIM and direct-mention handlers now run
`extractMessageImages` before calling handleMessage, gated on the
message having `files` of `image/png|jpeg|webp|gif` mimetype. Failed
file fetches log a warning and skip.

7 new tests covering handleMessage image attach + persistence stripping,
empty-text-with-images, and both adapter translations.

Closes #26
Co-Authored-By: Claude Opus 4.7 <[email protected]>

handleMessage now returns { text, thinking? } instead of a bare string.
When the Ollama backend emits message.thinking (qwq, gpt-oss,
deepseek-r1, etc.), app.js renders the reply as a Slack Block Kit
message with a context block showing an italicized "Thinking: …"
trace above the actual reply text.

Wiring:

- New OLLAMA_THINK env var. Accepts true/false (or 1/0/yes/no) and
  low/medium/high. Parsed in deps.js, passed to makeOllamaChat at
  construction time.
- Ollama adapter forwards the think param on every chat() call and
  surfaces response.message.thinking as result.thinking.
- handleMessage carries the trace through the tool dispatch loop —
  only the final non-tool response's thinking is surfaced.
- Thinking traces are NOT persisted to convoStore: ephemeral metadata,
  same as tool call traffic.
- Long traces are clipped to 1200 chars in the Slack context block to
  keep messages readable.

Gemini support for thinking deferred — gemini-3-flash-latest has a
thinking field but its API shape is still settling; can be added to
makeGeminiChat without further changes to handleMessage.

6 new tests across handleMessage + Ollama adapter (think param wiring,
trace surfacing, persistence stripping).

Closes #27
Co-Authored-By: Claude Opus 4.7 <[email protected]>

The post-then-delete dance for the "thinking" indicator created message
churn, occasional delete failures to log around, and ugly Slack history.
Reactions are the right primitive for "I'm working on this" — Slack
ephemeralizes them for free.

- `addThinkingReaction` / `removeThinkingReaction` replace
  postThinking / clearThinking. Both handlers add 🧠 to the user's
  message and remove it before replying.
- manifest.yaml: adds reactions:read and reactions:write scopes.
- Drops the THINKING_MESSAGE env var, lib/deps.js thinkingMessage field,
  and matching field destructure in app.js — no longer needed.
- Reply path simplifies: no more `let thinking = null` mutation, no
  post-and-track ts threading through the try/catch.

Closes #28
Co-Authored-By: Claude Opus 4.7 <[email protected]>

Channel @-mentions used to bail entirely on threaded messages, and
top-level mentions replied at the channel root — which floods the
channel for any back-and-forth. Now Data threads its replies:

- @DaTa at top level -> reply starts a thread rooted at the mention
- @DaTa inside an existing thread -> reply continues that thread
- Tool side effects (image uploads, joke posts, asimov recitation,
  etc.) also land in-thread because buildToolsFor plumbs thread_ts
  through into chat.postMessage and files.uploadV2.

Bail conditions in the direct-mention handler are tightened to just
{ bot_profile, bot_id, edited } — message.thread_ts and
message.parent_user_id no longer cause Data to drop the message, so
follow-up @-mentions inside threads Data started are now answered.
The bot_id/bot_profile guard still prevents loops with other bots.

DMs are unchanged — they reply flat as before.

Closes #29
Co-Authored-By: Claude Opus 4.7 <[email protected]>